Tester des classes serveur côté client par Nicolas FRANK (nicolas.frank@laposte.net)

(ou comme faire des tests JUnit sur les interfaces Locales des EJB 2.0).

  1. version du 28/01/2003 : 1ère publication en français (english version coming soon).
  2. version du 15/09/2003 : support des classes helpers (classes téléchargés avec le test)

Résumé

Tester des classes serveur peut poser problème notamment quand il s'agit de tester des Interface Locale EJB 2.0.

Déployer les classe de test côté serveur, nécessite de redéployer le serveur régulièrement lors de leur mise au point pour que les modifications soient prise en compte.

Cet article présente une méthode consistant à télécharger la définition de la classe de test à partir du client pour l'exécuter au sein d'un SessionBean.

Un package téléchargeable, permet de tester et de mettre facilement en pratique ce concept.

Présentation

Dans une architecture J2EE 1.3 classique avec un container EJB, les appels client aux EJB entity lui sont cachés via le pattern Façade.

Les EJB entity n'ont généralement plus de raison d'exposer d'interface Remote, tout accès se faisant par leur interface Locale à partir d'EJB Session déployés dans le même container (les Façades). De même les Sessions peuvent n'exposer certaines méthodes qu'à travers leur interface Locale si elle ne doivent pas être utilisées par un client.



Dans cette configuration, il devient difficile de construire des tests unitaires exhaustifs appelables à partir du client, puisque celui ci ne peut invoquer directement l'EJB entity (dans le diagramme précédent, impossible de tester la méthode getAccountDTO() à partir du client).

Les tests doivent donc être instanciés coté serveur dans la JVM du container.

Aujourd'hui, Junit est communément utilisé comme framework de test. Pour ceux qui ne le connaîtrait pas, il suffit dans le cadre de cet article, de savoir que :

- Les classes de test doivent étendre la classe de base junit.framework.TestCase.

- Les méthodes de test doivent être public et toutes commencer par test (ex : public void testSomething())

- Les tests d'un TestCase sont executés en passant le TestCase à une classe nommée TestRunner qui appellera ses méthodes commençant par test (TestRunner.run("MyTestCase" )).



Toute nos classes de test seront donc des TestCases.



La démonstration suivante présente une méthode permettant de mettre en place un mécanisme efficace afin de tester un TestCase coté serveur en n'utilisant que le container EJB du serveur d'application (par opposition au framework Cactus qui nécessite un container de Servlet).



1. Le TestRunner SessionBean :



La première idée simple est d'utiliser un EJB Session Stateless côté serveur auquel on indiquera par un appel client le TestCase à executer sur le serveur.

Remarque (et limitation que nous ferons tomber par la suite): Ce TestCase devra être dans le classpath du container. 

            public class TestRunnerBean implements SessionBean {

                public void playTestCase(String className) throws ClassNotFoundException {
                    Class testCaseClass = Class.forName(className);
                    // pour l'instant, on ne s'occupe pas de récupérer l'état final du TestCase…
            TestRunner.run(testCaseClass);
                }
            }
Il suffira donc d'écrire des TestCases tout à fait classiques qui appellent directement les Local Interfaces et autres ressources disponibles uniquement coté serveur. Bien sur le TestRunnerBean ne sera déployé que dans un serveur de test et jamais en production.



Ce schéma de fonctionnement recèle néanmoins une grosse contrainte lors de la phase de développement et de mise au point du TestCase : Pour modifier ou ajouter un TestCase, il est nécessaire de redéployer le serveur EJB, en y incluant la classe modifiée pour qu'elle soit trouvée par le ClassLoader du serveur.





2. Chargement dynamique de la définition de la classe de test :



Pour simplifier cela, l'idéal serait de pouvoir transférer dynamiquement le bytecode de la classe de test au serveur, pour qu'il la charge dans la JVM serveur et l'exécute.



… et bien allons y !



Côté client, il suffit de transférer le TestCase sous forme d'un flux de bits vers le serveur (En utilisant ClassLoader.getSystemClassLoader().getResourceAsStream(className) )



Côté serveur, il faut ensuite réinstancier la classe à partir du flux. Le ClassLoader traditionnel charge les classes à partir des fichier .class disponibles dans son classpath . Dans notre cas, il nous faut un ClassLoader capable de les créer à partir d'un flux de byte envoyé par le client.



Pour cela il faut construire un ClassLoader capable de créer une classe à partir d'un tableau d'octets.

Il suffit de surcharger la méthode loadClass(String className, boolean resolve) du java.lang.ClassLoader pour qu'il charge la classe à partir du tableau d'octets transmit que l'on fournira dans son constructeur (ClassLoader (public ByteClassLoader(byte[] classAsByte, String className) )).



Le package remoteTester :



Plutôt que de trop long discours, j'ai développé un package permettant de mettre en pratique ma démonstration et qui je l'espère vous sera aussi utile pour mettre réellement en pratique vos tests serveur.



Ce package se nomme remoteTester. Comme vous pouvez le constater, son arborescence cherche à coller le plus possible à celle de junit :



Le principal package runner, Contient la classe TestRunner, qui sera utilisée côté client pour executer les TestCase.

Le package server sera déployé que côté serveur (surprenant, non ;-)), puisqu'il contient le TestRunner Session Bean. (les interfaces Remotes seront également déployées côté client).



Le package test contient 2 exemples permettant de tester le remoteTester.

Le TestCase MySSTestCase fait appel à un EJB via son interface locale afin de démontrer l'intérêt principal du remoteTester. Le main de ce TestCase fait appel au remoteTester.TestRunner pour s'exécuter sur le serveur.

Je fournis une configuration prête à tourner sous Jboss (ear prêt à être déployé et script ant (le script est à adapter à votre configuration)). Cette configuration est très facilement adaptable à n'importe quel serveur d'application, puisque le seul fichier propriétaire est le fichier jboss.xml que vous remplacerez par celui de votre fournisseur de « boîte pour grains de café » préféré.

A noter que côté client, pour exécuter les tests, vous devrez placer un fichier jndi.properties dans le classpath client afin de pouvoir localiser le serveur d'application.

Futures améliorations



- Support des classes inner